Transformation Language Integration Based on Profiles and Higher Order Transformations

For about two decades, researchers have been constructing tools for applying graph transformations on large model transformation case studies. Instead of incrementally extending a common core, these competitive tool builders have repeatedly reconstructed mechanisms that were already supported by other tools. Not only has this been counterproductive, it has also prevented the de nition of new language constructs independently of a speci c transformation tool. Moreover, it has complicated the comparison of transformation languages. This paper describes a light-weight solution to this integration problem. The approach is based on executable transformation modeling using a small UML prole and on higher order transformations. It enables the integration of graph transformation tools such as Fujaba, VMTS and GReAT. The paper illustrates the approach by discussing the contribution of a Copy operator to any of these tools. Other language constructs can be realized similarly, without locking into speci c tools. 1 Problem: Lack of Portability and Reuse This paper tackles the integration problem of model transformation tools in general but focuses on graph transformation tools. Graph transformation gained industrial credibility in the nineties, thanks to the application of the Progres language (and tool) within industrial tool integration projects [1]. One of Progres' shortcomings was that it relied on a rather limited language for metamodeling. Moreover, some of its control ow constructs were rather ad-hoc compared to standard notations such as activity diagrams. After working within the Progres team, Zündorf showed how these two limitations could be overcome by de ning Story Diagrams as a new graph transformation language based on the UML [2]. Due to some interoperability issues with the C implementation of the Progres tool [3], a new Java based tool called Fujaba was implemented for these Story Diagrams [4]. Unfortunately, no mechanisms for reusing the advanced pattern matching libraries of Progres were available. Consequently, a lot of existing functionality had to be implemented again. In fact, some of Progres' language constructs are not yet supported by any other tool. In parallel to Fujaba, another graph transformation tool called GReAT was implemented for the Windows platform [5]. Similar to Fujaba and Progres, GReAT also supported pattern matching, rewriting, rule iteration, etc. However, one did not yet de ne metamodels for integrating the di erent tools' editors, analyzers or compilers. Although this kind of prototyping was natural for the rst generation of tools, the disadvantages became clearly visible when even more tools were constructed. With the advent of the MDA, a new generation of tools (such as MOLA [6] and VMTS [7]) was constructed by competing research groups. Unfortunately, these tools have proposed yet another syntax for graph transformation constructs with the same underlying semantics. Moreover, none of the graph transformation tools rely on libraries to reuse existing infrastructure for pattern matching, control ow, etc. Although the existence of multiple tools ensures healthy competition, today's tool landscape su ers from (1) the lack of portability of transformation models across di erent editors, and (2) the lack of reuse of compiler/interpreter infrastructure. This paper presents language engineering techniques to solve these two problems. The remainder of the text is structured as follows: Section 2 explains how standard UML pro le syntax enables editor and repository independence, Section 3 describes how transformation language behavior can be shared across tools, Section 4 describes how the approach has been applied to contribute a new transformation language construct in a tool-independent manner, Section 5 discusses how the approach still applies for quite advanced and seemingly toolspeci c language constructs, Section 6 presents related work, Section 7 presents an outlook for future work and Section 8 concludes. 2 Extensible Transformation Language: Standard Pro le The rst step to transformation tool integration is the agreement on a metamodel for all mainstream transformation language constructs. The metamodel should meet the concerns of transformation writers, while these may be in con ict with those of transformation tool builders. Since transformation writers need to write and debug transformation models, they want a transformation language with a human-readable concrete syntax. Moreover, they want to be able to use the editor of the most user-friendly transformation tool (automatic completion, interactive debugging, ...). Finally, they may want to rely on the optimizer of one tool and potentially deploy the result using integration components of yet another transformation framework (EMF compatible Java, JMI compatible Java, Windows compatible C++, Unix compatible C++, ...). Since transformation tool builders need to provide such functionality, they want a simple metamodel and reuse existing software whenever possible. 2.1 Metamodel: UML 1.5 It turns out that a small subset of the UML 1.5 metamodel reconciles the requirements of transformation writers with those from tool builders. More specifically, UML class and activity diagrams resemble the concrete syntax of popular graph transformation languages such as Story Diagrams, MOLA and VMTS quite closely. UML 1.5 relates to an ISO standard and is supported by quite a number of mature tools (commercial as well as open source). In contrast, UML 2 based tools tend to di er more at the metamodel level. Moreover, the UML 2 metamodel is designed to integrate several diagram types that are irrelevant for transformation modeling. This complicates the metamodel structure and thus unnecessarily increases the implementation e ort for tool builders. Transformation writers that insist on using a UML 2 editor can apply a standard converter for mapping UML 2 pro le, class and activity models back to UML 1.5. At the other end of the universal-to-domain-speci c spectrum, the Graph Transformation eXchange Language (GTXL [8]) does not su er from the metamodel complexity overhead associated with the UML standards. However, besides more problems discussed in Section 6, GTXL models have no standard concrete syntax beyond XML. Therefore, it does not satisfy the readability concerns of transformation writers. Section 6 also discusses the drawbacks of the Queries/Views/Transformations (QVT [9]) languages. Among other problems, QVT standardizes even more than is supported by mainstream transformation tools. Therefore, it requires much more implementation e ort than the lightweight UML approach presented here. 2.2 Extensions for Transformation Modeling Among the domain-speci c extensions, a UML based transformation modeling language needs a means to relate an activity in a control ow to a particular rewrite rule. Such extensions could be realized using MOF extensions of the UML metamodel. However, this approach is undesirable for several reasons. First of all, such heavy-weight extensions break the compatibility of the standard transformation language with general purpose UML editors. More speci cally, at the implementation level there would be several incompatibilities in MOF repository interfaces, XMI schema's, etc. Similarly, transformation tools that would use MOF extensions to realize language constructs beyond the core transformation standard would break compatibility with tools that only support that core. Fortunately, the UML metamodel is designed for enabling language extensions without the need for a metamodel change. Essentially, there is a mechanism to introduce (1) the equivalent of a new metaclass (MOF M2) as a library element (MOF M1), and (2) the equivalent of a new MOF attribute (MOF M2) as another kind of library element (MOF M1). The mechanism is known as UML Pro les . New virtual metaclasses are called Stereotypes and new virtual metaattributes are called Tagged Values . Table 1 displays the concrete stereotypes and tag de nitions from the proposed UML Pro le for Transformation Modeling. The core pro le only supports the basic graph transformation concepts: it has the notion of a rewrite rule (matched elements, created elements, deleted elements and updated elements) and control ows (iterative loops, conditionals and called transformations). Pro le Element Related UML Constructs Meaning ModelTransformation , Method Callable Transformation motmot.transformation Method, Link from method to tag Package, Activity Diagram controlled rewrite rules loop , State Iterative loop over rule, each time Transition iterative execution of nested ow success , failure Transition Match/Mismatch of rule motmot.constraint State, String Application condition on state tag Class, String Application condition on node link , code State, String Call to transformation motmot.transprimitive State Link from state in a ow to tag Package, Class Diagram(s) a rewrite rule motmot.metatype tag, Class Type of rewrite node bound , Class Parameter node, or node matched by previously executed rule create , destroy Class, Association Created/Destroyed elements Attribute (initial value) Node attribute updates closure , Association Transitive closure for link label Table 1. A basic (core) UML Pro le for Transformation Modeling. These syntactical constructs already provide a large portion of the expressiveness of today's graph transformation languages. Nevertheless, we do not want to standardize all transformation tools prematurely to this common denominator. Instead, new stereotypes and tagged values can be de ned in UML models that extend the core pro le. Such extensions can be made publicly available to extend any other UML editor with the new transformation language constructs. In summary, the proposed standard metamodel for exchanging transformation models consists of the class diagram (core), activity diagram (activities), and pro le (extension mechanisms) packages of the UML metamodel. 2.3 Evaluation of the Core Transformation Modeling Pro le To validate whether the core transformation pro le is still human-friendly, it has been used to model a variety of transformation problems using o -the-shelf UML tools. More speci cally, several refactorings (Pull Up Method, Encapsulate Field, Flatten Hierarchical Statemachine and others) and re nements (e.g., a translation of UML to CSP) have been modeled using commercial tools, without any plugins speci c to the proposed transformation modeling pro le [10]. An cognitive evaluation based on the framework of Green [11] con rms that the standard transformation language is usable even without any user interface implementation e ort from transformation tool builders. Obviously, in an industrial context, one would rely on auto-completion and debugging plugins. However, the e ort required for constructing such plugins would still be smaller than the e ort for constructing a QVT editor from scratch. As discussed above, the proposed integration architecture enables transformation tool builders to specialize in complementary features. One tool builder (e.g., the MOLA team) can provide syntactical sugar on top of the proposed pro le while another one (e.g., the VMTS team) can invest in optimizations. One tool builder (e.g., the MOFLON team) can provide integration with MOF based repositories (EMF and JMI) while another tool builder (e.g., the Progres team) can o er a C++ backend. To evaluate this architecture in practice, the MoTMoT tool provides a bridge from the proposed pro le to JMI based repositories without o ering a dedicated transformation model editor. Instead, MoTMoT relies on third-party editors such as MagicDraw 9 or Poseidon 2 [12]. To illustrate the core pro le, Figure 1 shows the control ow and a rewrite rule for the Extract Interface Where Possible refactoring. Within the context of a package, the refactoring should mine for commonality between classes. More speci cally, by means of an interface it should make explicit which classes implement the same method signatures. The transformation presented in this paper has been created by master-level students, after a three hour introduction to the proposed approach to transformation modeling. The transformation ow shown on Figure 1 (a) controls the execution of three rewrite rules. The matchOperations rule associated with the rst activity is used to check the precondition of the refactoring. More speci cally, it matches only for those methods that have the same signature. Since the activity is decorated with the loop stereotype, it is executed for every possible match. Moreover, the two subsequent activities are executed for each match as well due to the each time stereotype on the outgoing transition. Due to the absence of a loop stereotype, the second activity is executed only once for each match of the rst activity. The second activity is associated with the rewrite rule shown in Figure 1 (b). The class1, class2, m1 and m2 nodes are bound from the execution of the previous rule. The rule matches the visibility of the second method (m2 ) in order to create a copy of that method in the node commonOperation. The operation is embedded in the newInterface node that is newly created, as speci ed by the create stereotype. The newly created interfaceLink1 and interfaceLink2 elements ensure that class1 and class2 implement the new interface. The third activity is executed for all possible matches of its rewrite rule. In this rewrite rule (not shown due to space considerations), all parameters from the new operation are created based on the parameters of m1 and m2. To complete the discussion of this example, consider the two nal states shown in the top of Figure 1 (a). The left nal state is reached when the precondition (activity 1) fails. The right nal state is reached otherwise. The nal states are used to return a success boolean value for the transformation that is modeled by Figure 1 (a). Speci c tools provide small variations on the syntactical constructs presented in this example. For example, the Fujaba and MOLA tools visually embed the rewrite rules (cfr., Figure 1 (b)) inside the activities of the control ow (cfr., Figure 1 (a)). However, for example VMTS does not rely on such an embedded representation. Therefore, the proposed concrete syntax resembles mainstream graph transformation languages in a satisfactory manner. (a) Control Flow (b) Rewrite Rule Fig. 1. Extract Interface refactoring, modeled using the core pro le. 3 Exchangeable Semantics: Higher Order Transformations In the previous section we showed how transformation languages can be integrated at the syntactical level. This relates to the editors and repositories of transformation tools. In this section we show how the semantics of the transformation modeling pro le can be extended with the help of higher order transformations. This relates to the compilers or interpreters of transformation tools. In general, higher order transformations are de ned as transformations that consume and/or produce transformation models. In the context of this paper, the role of higher order transformations is to transform transformation models that conform to an extension of the pro le into transformation models that conform to the pro le without the new language construct. The semantics of the core pro le is assumed to be well-understood: it is merely a standard syntax for what has been applied for two decades already. A key to the proposed integration architecture is that the higher order transformations themselves are modeled using the core pro le for transformation modeling. Therefore, any transformation engine that supports the core pro le can execute the higher order transformations. Consequently, any such engine can normalize transformation models that apply a new language construct into more primitive transformation models. In general, a transformation tool may execute a series of publicly available higher order transformations before executing the result on its native graph transformation engine. In the case of performance problems (that we have not encountered so far), some tools might directly generate optimized code for particular transformation language constructs. In that case, the higher order transformations may be used for checking the correctness of the optimized code. In summary, higher order transformations ensure that new graph transformation language constructs can be executed by all tools that support the core transformation modeling pro le. On the one hand, this rewards the creator of the language construct with an instant adoption across a set of tools. On the other hand, this relieves tool builders from implementing constructs that have been de ned by others. 4 Example Pro le Extension: Copy Operator This section explains how we contributed a Copy operator according to the proposed integration architecture. Subsection 4.1 describes the syntactical extension of the pro le. Subsection 4.2 presents the higher order transformation that makes the operator executable in a tool-independent manner. Remark that copy operations can already be programmed with the core pro le: one can specify match and create operations explicitly for all elements that need to be copied. For example, the rewrite rule from Figure 1 (b) explicitly enumerates which properties (name and visibility) from the m2 node need to be copied to the commonOperation node. However, such transformation speci cations are undesirably low-level. One would like to model declaratively which nodes should be copied without worrying about the attributes (cfr., name) and associations (cfr., visibility) of the related metaclasses (cfr., Operation).